綠燈的 CI 管線令人安心。它告訴團隊:團隊選擇執行的那些自動化檢查都成功完成了。但它無法證明產品是正確的。一個系統可以通過每一項自動化測試,卻仍然算錯折扣、把資訊暴露給錯誤的使用者、產出聽起來頭頭是道但實際錯誤的 AI 回應,或在沒人想到要自動化的情境中表現異常。正因如此,QA 工程不是單純把測試數量極大化,而是理解風險,並決定測試心力應該投入在哪裡。
這張表展示的是一個圍繞**影響程度(impact)、發生可能性(likelihood)與可偵測性(detectability)**建立的風險導向方法。一個業務影響高、發生機率高、卻不容易被察覺的缺陷,值得比一個使用者和監控系統都能立即發現的外觀問題深入得多的測試。因此,測試深度應該跟著風險走,而不是把每個功能一視同仁。
想想優惠券疊加(coupon stacking)。假設一個應用程式允許多項促銷互相作用,而某個罕見的組合導致訂單最終金額被算錯。它的影響高,因為涉及金錢;發生可能性可能也高,因為客戶經常使用促銷;可偵測性卻低,因為介面上顯示的總額看起來可能完全正常。一個基礎的自動化測試可能通過,因為每一張優惠券單獨使用都正確。QA 需要的是更深入的情境:組合、邊界值、互相衝突的折扣,以及與獨立計算的預期總額進行對帳(reconciliation)。
相較之下,像標籤位置跑版這類版面問題:它可能經常發生,但影響相對低、可偵測性高。煙霧測試(smoke test)、目視檢查或監控流程也許就夠了。在這個問題上投入與財務計算錯誤相同的 QA 資源,只會浪費資源,同時讓高風險的行為得不到充分的測試。
AI 帶來另一個問題:一個回應可以看起來正確,卻其實不正確。傳統軟體對相同的輸入通常產出確定性的結果,而 AI 系統可能生成不同的措辭、解讀或決策。有四種風險變得格外重要:幻覺(hallucination)、提示詞注入(prompt injection)、失控成本(runaway cost)與延遲(latency)。
幻覺發生在 AI 系統生成聽起來合理、卻缺乏依據或根本錯誤的資訊時。想像一個自動化 QA 檢查,請 AI 驗證客服機器人是否正確解釋了公司政策。機器人給出了錯誤的資格期限,但 AI 評審只因答案聽起來連貫就判定為可接受。CI 轉綠了,產品卻正在給客戶錯誤的資訊。測試在技術上成功了;用來判定正確性的 oracle(測試 oracle)卻失靈了。
這正是黃金資料集、權威知識來源、確定性斷言與人工抽樣重要的原因。與其問另一個 AI「這個回應看起來正確嗎?」,QA 可以把關鍵事實與明確定義的預期值比對。AI 可以協助評估,但高風險的判斷不應完全依賴一個模型對另一個模型的附和。
提示詞注入帶來的是另一種問題,因為輸入本身就能操縱 AI 的行為。一段嵌入在客戶內容中的惡意或意外指令,可能叫模型忽略它原本的規則,或執行未經授權的動作。一般走的快樂路徑(happy path)自動化可能永遠不會暴露這個弱點。因此 QA 需要對抗性測試:互相衝突的指令、不受信任的文字、嘗試覆寫系統規則的輸入,以及驗證授權在 AI 層之外仍被強制執行的檢查。舉例來說,如果一個 AI 助理可以發起退款,後端仍然必須獨立驗證這個動作是否被允許。
失控成本說明了:功能的正確性並不是品質的唯一定義。一個 AI 工作流程可能產出正確的回應,同時卻意外地重複呼叫模型、處理不必要的大上下文,或陷入重試迴圈。每一項 CI 斷言都可能通過,而生產環境的成本悄悄翻了好幾倍。因此,QA 除了功能結果之外,還應該觀察 token 消耗、API 呼叫次數、重試行為、執行頻率與異常的使用模式。
最後,延遲可以把一個技術上正確的功能變成不可用的功能。一個 AI 回應可能很準確,卻在產品需要近即時互動時花上 20 到 30 秒。只檢查最終回應的功能測試會一直是綠燈。因此,效能測試必須建立可衡量的門檻,並在貼近真實的工作負載下觀察回應時間,而不是只問「回應最後有沒有來」。
| 風險 | 影響 | 可能性 | 可偵測性 | 測試深度 | 負責人 |
|---|---|---|---|---|---|
| 優惠券疊加金額算錯 | 高(金錢) | 高 | 低(只有對帳能發現) | 深:案例 + 對帳檢查 | QA + 財務 |
| 免運門檻邊界 | 高(金錢) | 中 | 中 | 深:邊界 + 等價類 | QA |
| AI 混淆兩種訂單狀態 | 高(信任、資料) | 高 | 低 | 深:黃金資料集 + 人工抽樣 | QA + 客服 |
| 提示詞注入導致未經授權的退款 | 高(金錢、權限) | 低 | 中 | 中:對抗性腳本 | 資安 + QA |
| 回覆延遲超過門檻 | 中 | 中 | 高 | 中:效能觀察 | SRE |
| 錯字與版面走樣 | 低 | 高 | 高 | 淺:煙霧測試 + 監控 | 自動化 |
這些例子揭示了一個重要的區別:測試自動化不等於 QA 工程。自動化回答的是「已經被編碼進測試裡」的問題;QA 還必須問:這些是不是該問的問題。
綠燈管線真正的意思是**「我們定義的檢查通過了」,而不是「這個系統沒有問題」。** 如果預期結果不完整、AI 評審出現幻覺、測試資料漏掉重要邊界,或者整個套件從不量測成本與延遲,CI 可以自信滿滿地回報成功,而一個真實的落差仍然存在。
風險導向測試就是那道防線。高影響、難以偵測的失敗值得更深入的驗證、獨立的事實來源、對抗性情境、對帳,有時還需要人工審查。低風險、容易發現的問題則可以更依賴煙霧測試與自動化。當 AI 同時成為產品與測試工作流程的一部分,QA 工程師的責任變得更加重要:不要只驗證測試轉綠了——要驗證「綠燈」確實代表業務與使用者所需要的行為。